Relational databases came into common use in computers over twenty years ago. Despite improvements in database software and new methodologies, relational databases remain the mainstay of database management systems (DBMS). Hardware vendors originally supported proprietary database management systems which ran primarily on machines manufactured by the hardware vendor. Software developers later developed database management systems that were more open and ran on computers made by several vendors. The database management systems were also ported to run under various operating systems. This gave the advantage of spreading the cost of development over more sites and also uncoupled the dependence between hardware vendors and software vendors. Third party support and training also became more common.
Database management systems also became separated into client-side software and server-side software. This meant that the server-side software was decoupled from software having to do with the display, use, and formatting of the data received from the database. In particular, server-side software often handled mostly queries of existing data along with updates of existing data and insertion of new data.
Modem electronic commerce such as commerce over the Internet or business-to-business electronic commerce has placed increased demands on many servers. This has also made frequent upgrades necessary. Company mergers and acquisitions frequently make it necessary to incorporate large amounts of data from unexpected sources. Customer expectations also make it necessary to upgrade hardware to keep up with the faster response times users expect even though system loads may be increasing as well.
When installing, upgrading or replacing database servers it is desirable to establish the transaction handling requirements that must be met, and compare these requirements with the DBMS transaction handling processing capabilities of available systems.
In some situations, a required or desired transaction handling capability is based mainly on the capability of a known system. It may be the case that a given brand name DBMS server is believed to satisfy a current or future requirement, and the tpmC capability of that DBMS server is available from the vendor and/or from the tpmC organization database. A more accurate performance value could, in theory, be derived from a series of more specific description of the requirements. It may be the case that the user has a more specific description of the requirements for a system, such as detailed transaction specific information.
When evaluating such systems, it would be desirable to allow for some margin or headroom in capacity. If a system was specified to run too close to capacity, then it lo might become backlogged and deny service when bursts of activity exceeded the average workload. It would also be desirable to factor in hardware utilization limits for specific hardware components. An upper utilization limit could reduce the likelihood of under-capacity and the resulting bottleneck. A lower utilization limit could reduce the likelihood of over-capacity and the resulting excessive spending.
What would be desirable therefore is a system for factoring in hardware utilization limits in determining hardware requirements. This may include allowing for changes in the hardware utilization limits, with corresponding adjustments to the hardware requirements.